Hey Michele!

Can you explain this a bit more? I'll admit that ACL is not my strongpoint, and I can read the setfacl manual that you quoted, but I'm still not really sure what this would change :). Did the original command cause you problems? Was it doing something extra it didn't need to?

Thanks!

I think the explanation falls into these paragraphs:

 AUTOMATICALLY CREATED ENTRIES
       Initially,  files  and  directories  contain  only  the  three base ACL
       entries for the owner, the group, and others. There are some rules that
       need to be satisfied in order for an ACL to be valid:

       *   The three base entries cannot be removed. There must be exactly one
           entry of each of these base entry types.

       *   Whenever an ACL contains named user entries or named group objects,
           it must also contain an effective rights mask.

       *   Whenever an ACL contains any Default ACL entries, the three Default
           ACL base entries (default owner, default group, and default others)
           must also exist.

       *   Whenever  a  Default ACL contains named user entries or named group
           objects, it must also contain a default effective rights mask.

       To help the user ensure  these  rules,  setfacl  creates  entries  from
       existing entries under the following conditions:

       *   If  an  ACL contains named user or named group entries, and no mask
           entry exists, a mask entry containing the same permissions  as  the
           group  entry is created. Unless the -n option is given, the permis-
           sions of the mask entry are further adjusted to include  the  union
           of  all  permissions affected by the mask entry. (See the -n option
           description).

       *   If a Default ACL entry is created, and the Default ACL contains  no
           owner, owning group, or others entry, a copy of the ACL owner, own-
           ing group, or others entry is added to the Default ACL.

       *   If a Default  ACL  contains  named  user  entries  or  named  group
           entries, and no mask entry exists, a mask entry containing the same
           permissions as the default Default  ACL’s  group  entry  is  added.
           Unless  the  -n  option is given, the permissions of the mask entry
           are further adjusted to inclu  de  the  union  of  all  permissions
           affected by the mask entry. (See the -n option description).

so in a way trying to avoid automatic adjustment of the effective permissions of the mask. But yeah we need an expert opinion.

If the main goal of documentation ACL hints is to prepare directories to work in any condition, it should be better to have ACL winning on mask options.
You can say that anything in the involved directories at first installation time should not be covered by particular mask settings, but what if something in our applications creates files at runtime with particular ones?

yes I agree, we should merge this

@weaverryan an example of software that would write umasks while running is sqlite, so it could happen to have resources covered by an umask into the cache directory.
This is an example scenario where I would prefer to have an ACL setted to ignore it.

Using everyday a Debian derivate distro instead of Appleish products mwould make ACL problems more evident.

Thanks guys! I'll admit, I still don't really understand what this does, but I'm also pretty sure that's due to my lack of knowledge about the ACL's and masks themselves (but you seem to understand well). Anways, thanks for the change! :)

Thanks to you for the effort on documentation!

Hi,

just tried the new way on a Linux Mint 16 sytem using the -n parameter. In my system leads to an effective: r-x for both, www-data ($APACHEUSER) and the 'whoami'.

I deleted all acl rights but the standard for owner, group, other and retried. Always lead to #effective: r-x. As soon as i deleted the acl rights and used it without the -n parameter it worked like a charm. So there seem to be differences in the systems maybe?

When i used the commands via C&P before, it always worked for me on Debian 6/7 and Ubuntu 12.04 LTS.

Maybe there should be an additional hint?

EDIT (finally after serveral c&p errors):

sr972@main /var/www $ setfacl -bk app/cache
sr972@main /var/www $ getfacl app/cache
# file: app/cache
# owner: sr972
# group: sr972
user::rwx
group::r-x
other::r-x

sr972@main /var/www $ sudo setfacl -Rn -m u:"$APACHEUSER":rwX -m u:`whoami`:rwX app/cache app/logs
sr972@main /var/www $ sudo setfacl -dRn -m u:"$APACHEUSER":rwX -m u:`whoami`:rwX app/cache app/logs
sr972@main /var/www $ getfacl app/cache
# file: app/cache
# owner: sr972
# group: sr972
user::rwx
user:www-data:rwx       #effective:r-x
user:sr972:rwx          #effective:r-x
group::r-x
mask::r-x
other::r-x
default:user::rwx
default:user:www-data:rwx   #effective:r-x
default:user:sr972:rwx      #effective:r-x
default:group::r-x
default:mask::r-x
default:other::r-x

sr972@main /var/www $ setfacl -bk app/cache
sr972@main /var/www $ getfacl app/cache
# file: app/cache
# owner: sr972
# group: sr972
user::rwx
group::r-x
other::r-x

sr972@main /var/www $ sudo setfacl -R -m u:"$APACHEUSER":rwX -m u:`whoami`:rwX app/cache app/logs
sr972@main /var/www $ sudo setfacl -dR -m u:"$APACHEUSER":rwX -m u:`whoami`:rwX app/cache app/logs
sr972@main /var/www $ getfacl app/cache
# file: app/cache
# owner: sr972
# group: sr972
user::rwx
user:www-data:rwx
user:sr972:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:www-data:rwx
default:user:sr972:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

Wich version of ACL are you using?

@sr972 I think you should make another pull request and move the discussion on that one!

Yes @sr972 - can you open up a pull request with the changes and details? The truth is, this command seems to be very difficult to get right, and it's very very technical. So, if it's not working for you, it's likely not working for others, and I'd love to have a PR where we can discuss it (so it doesn't get lost!).

Thanks!

See #3712 - there is indeed now a problem with this command

Exactly for me on Linux, setfacl works as usual with -dR and -d option only... without -n option, because that cause rights problems.